---

This section details on the original issue you should resolve

<issue_title>mergenupkg breaks build pipeline in .NET 9; ci still using .NET 6</issue_title>
<issue_description>## Problem overview

I noticed Myriad's main branch had been ~mostly upgraded to .NET 9 but the package wasn't available on NuGet. There are two issues:

• The publish action is configured to install .NET 6 (and Windows — you probably don't want that). We should change this line to 9.x

• We can't publish the package anyway, because the mergenupkg build step is broken in .NET 9:

Myriad cadence$ dotnet tool restore
Failed to validate package signing.

Verifying dotnet-mergenupkg.3.0.0

Signature type: Repository
  Subject Name: CN=NuGet.org Repository by Microsoft, O=NuGet.org Repository by Microsoft, L=Redmond, S=Washington, C=US
  SHA256 hash: 0E5F38F57DC1BCC806D8494F4F90FBCEDD988B46760709CBEEC6F4219AA6157D
  Valid from: 4/9/2018 9:00:00 PM to 4/14/2021 9:00:00 AM

warn : NU3018: The repository primary signature found a chain building issue: RevocationStatusUnknown: An incomplete certificate revocation check occurred.
error: NU3037: The repository primary signature validity period has expired.
error: NU3028: The repository primary signature's timestamp found a chain building issue: ExplicitDistrust: The trust setting for this policy was set to Deny.

Package signature validation failed.

Instructions for reproduction

• Install .NET 9 SDK
• Run dotnet tool restore from repository root.

Proposed solution

• Publish myriad as a .NET tool and Myriad.Sdk as a separate package
• OR develop some solution to allow MSBuild to locate build scripts inside our dotnet tool install directory.

I'm leaning toward the first for simplicity sake. I tried to figure out how to make the second solution work, but it seems like more trouble than its worth. Let me know which approach you prefer and I'll submit a PR.</issue_description>

Comments on the Issue (you are @copilot in this section)

@7sharp9 Having two packages makes using it more difficult to use though though right?

I think, (I forget now because so much time has passed) that @enricosada used mergenupkg due to a limitation in dotnet tools at that point in time. I just cant remember now. When we were both working at Jet the basis for the package architecture came from Falanx which has the same build steps and cache checking. I mean, you dont need to know all this, I'm just thinking out loud :-)</comment_new>
<comment_new>@7sharp9
I wonder if the issue was that the myriad.sdk could not have the tool as a dependency?</comment_new>
<comment_new>@7sharp9
To be honest I think I've forgot most of the issues over time. I wonder if the Myriad.Sdk could prompt to do an install if it detects the absence of the tool?</comment_new>
<comment_new>@7sharp9
Also, if there was some warning and I got round to updating a template that would even things out.</comment_new>
<comment_new>@7sharp9
Anecdotally it should be ok to split, its just getting round to looking at it an analysing to ensure theres a good experience and updating the docs. And fixing the docs, whew!</comment_new>